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Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides details of the Voice Profile for Internet Mail
   (VPIM) directory service.  The service provides the email address of
   the recipient that is given a telephone number.  It optionally
   provides the spoken name of the recipient and the media capabilities
   of the recipient.

   The VPIM directory Schema provides essential additional attributes to
   recreate the voice mail user experience using standardized
   directories.  This user experience provides, at the time of
   addressing, basic assurances that the message will be delivered as
   intended.  This document combines two earlier documents, one from
   Anne Brown and one from Greg Vaudreuil, that define a voice messaging
   schema into a single working group submission.
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1.  Scope

1.1.  Design Goals

   The VPIM directory Schema (VPIMDIR) is accessed from outside the
   enterprise or service provider domain using the recipient's telephone
   number.

1.2.  Performance Constraints

   Once the identity of the VPIM directory server is known, the email
   address, capabilities, and spoken name confirmation information can
   be retrieved.  This query is expected to use LDAP [LDAP], a
   connection-oriented protocol.  The protocol transaction includes
   multiple packet round-trips to execute the query and retrieval and is
   considered to be the highest latency element of the messaging
   service.  Further, retrieval of the confirmation information may
   require the return of a spoken name segment of up to 20kbytes (5
   seconds at 4kbytes/second).  Over a sufficiently engineered Internet
   connection, a 1250 ms response time is believed to be achievable over
   the Internet at large.
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1.3.  Scaling Constraints

   A service provider's namespace is expected to include entries for
   tens of millions of subscribers in a flat namespace based on the VPIM
   inter-domain address form: telephone_number@domain_name.  A large
   corporation may have a hundred-thousand entries, while a large
   service provider may have tens of millions of entries in a single
   domain.  It is expected that there will be a single public address
   validation service for a given service provider's network.  It is
   believed that existing directory technology, including horizontal
   scalability through replication, will provide sufficient transaction
   throughput within the required latency requirements to address this
   need.  The only fundamental, new requirement this application imposes
   on directory servers, beyond similar existing services, is the
   ability to return the recipient's spoken name.  Preliminary
   investigation suggests that storage and retrieval of a spoken name
   will not add appreciable latency; however, it will add to the need
   for storage capacity.

1.4.  Reliability Constraints

   DNS provides well-documented redundancy and load-balancing
   capabilities for the VPIMDIR.  However, the latency requirements to
   the end-user may not permit client-side fail-over to a secondary
   server and may require the directory server to be implemented as a
   high-availability service.

2.  The VPIMUser Directory Schema

      (IANA-ASSIGNED-OID.1 NAME 'vPIMUser'
              SUP 'top'
              AUXILIARY
              MUST ( vPIMRfc822Mailbox $
                     vPIMTelephoneNumber )
              MAY  ( vPIMSpokenName $
                     vPIMSupportedUABehaviors $
                     vPIMSupportedAudioMediaTypes $
                     vPIMSupportedMessageContext $
                     vPIMTextName $
                     vPIMExtendedAbsenceStatus $
                     vPIMMaxMessageSize $
                     vPIMSubMailboxes ) )

   When present, the vPIMUser object contains information useful for
   verifying that the dialed telephone number corresponds to the
   intended recipient.  This object also provides capability information
   and mailbox status information useful for guiding composition by the
   sender and for setting delivery expectations at sending time.
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2.1.  vPIMTelephoneNumber

   The attribute vPIMTelephoneNumber is the full E.164 form of the
   telephone number [E164], including any sub-addressing portion.  The
   normal search will be for this attribute.

      (IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber'
                          EQUALITY caseIgnoreMatch
                          SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} )

   Example: A North American telephone number with the sub address of 12
   would be represented as "+12145551212+12".

   Note that vPIMTelephoneNumber is, by default, a multi-valued
   attribute.  But if an entry has multiple values for this attribute,
   those values MUST be distinct from each other in the telephone number
   portion.  It is expected that each submailbox of a single telephone
   number will have its own vPIMUser entry.

   The vPIMTelephoneNumber differs from telephoneNumber in [LDAP] in its
   support for sub-addressing information and its use as a voice
   messaging address.  In most cases, these values will be the same.

   The telephone number is stored with no parenthesis, spaces, dots, or
   hyphens.  The leading '+' and the '+' delineating the submailbox are
   required markup.

2.2.  vPIMRfc822Mailbox

   The attribute vPIMRfc822Mailbox stores the inter-domain SMTP address
   of the voice mailbox associated with a given telephone number.  It is
   defined as a distinct attribute to distinguish it from the
   rfc822Mailbox attribute that may be used for other purposes.
   Although it would be preferable to define vPIMRfc822Mailbox as a
   subtype of rfc822Mailbox, it is defined here as an entirely new
   attribute because some directory implementations do not support sub-
   typing.

      (IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox'
                        EQUALITY caseIgnoreIA5Match
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

2.3.  vPIMSpokenName

   The vPIMSpokenName attribute is an octet string and MUST be encoded
   in 32 kbit/s ADPCM exactly, as defined by [32KADPCM].  vPIMSpokenName
   shall contain the spoken name of the user in the voice of the user.
   The length of the spoken name segment MUST NOT exceed five seconds.
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   Private or additional encoding types are outside the scope of this
   version.

      (IANA-ASSIGNED-OID.2.3 NAME 'vPIMSpokenName'
                        EQUALITY octetStringMatch
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000}
                        SINGLE-VALUE )

2.4.  vPIMTextName

   The text name is designed to be consistent with the unstructured
   text name databases used for calling name delivery service of
   caller ID.

      (IANA-ASSIGNED-OID.2.4 NAME 'vPIMTextName'
                        EQUALITY caseIgnoreMatch
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20}
                        SINGLE-VALUE )

2.5.  vPIMSupportedAudioMediaTypes

   The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of
   audio encodings that can be received at the address specified in
   vPIMRfc822Mailbox.

      (IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes'
                        EQUALITY caseIgnoreIA5Match
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   This is a multi-value attribute.  The allowable values for this
   attribute are the MIME audio subtypes registered with IANA.  Non-
   standard and private encoding types must be indicated by prepending
   the new type name with either "X-" or "x-".

   Because ADPCM is a required format, the audio32kadpcm value must be
   listed if this attribute is present.

2.6.  vPIMSupportedMessageContext

   The message context provides guidance to the sender about the message
   contexts the recipient is likely to accept.  Message context provides
   less precise information about a given recipient's capabilities than
   a list of media types.  However, given the growing role of media-
   conversion gateways, the context indicator provides more useful
   guidance to a sender in a "unified messaging" environment.
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      (IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext'
                        EQUALITY caseIgnoreIA5Match
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   This is a multi-value attribute.  The set of valid message context
   values is defined in [CONTEXT].

2.7.  vPIMExtendedAbsenceStatus

   It is common to have an attribute that indicates to the subscriber
   whether the recipient is accepting messages during his absence.  This
   feature -- called "extended absence" -- provides an advisory message
   at sending time.  It is similar in concept to "vacation notices"
   common for textual email, but has its own cultural and operational
   nuances.

      (IANA-ASSIGNED-OID.2.7 NAME 'vPIMExtendedAbsenceStatus'
                        EQUALITY caseIgnoreIA5Match
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
                        SINGLE-VALUE )

   The three values defined are:

            "Off", "On", "MsgBlocked"

   "Off" indicates that the recipient either does not support extended
   absence or has not set such an indicator.  "Off" is the default
   condition if this attribute is not returned.

   "On" indicates that the recipient has set an extended absence
   indicator, but the mailbox is still accepting messages for review at
   an unspecified future time.

   "MsgBlocked" indicates that the recipient has set an extended absence
   indicator and the mailbox is currently configured to reject incoming
   messages.  Messages SHOULD NOT be sent to the recipient if this value
   is returned in the vPIMExtendedAbsenceStatus attribute.

2.8.  vPIMSupportedUABehaviors

   Internet mail does not provide facilities for the sender to know
   whether the recipient supports a number of optional features that can
   be requested or indicated in the RFC822 headers.  This attribute
   provides a list of the attributes, considered optional by VPIM and
   other vendor-specific attributes, that may be supported by the
   recipient.  If this attribute is not supported, only those attributes
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   listed as mandatory in VPIM are assumed to be supported.  Undisclosed
   behaviors may be indicated in the RFC822 message; however, there is
   no assurance by the receiving system of their support.

      (IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors'
                        EQUALITY caseIgnoreIA5Match
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   The following behaviors are defined:

            MessageDispositionNotification
            MessageSensitivity
            MessageImportance

   The presence of the MessageDispositionNotification value indicates
   that the recipient will send an MDN in response to an MDN request.

   MessageSensitivity indicates that the recipient fully supports the
   sensitivity indication as defined in VPIM [VPIMV2].

   MessageImportance indicates that the recipient fully supports the
   importance indication as defined in VPIM [VPIMV2].

   These may be further extended without standardization to include
   proprietary user interface functional extensions.  These proprietary
   extension values must be prefixed with an "X-" or "x-".

2.9.  vPIMMaxMessageSize

   At the time of composition, the message can be checked for acceptable
   length using the maximum message size attribute.  Maximum message
   size is an attribute usually configured by policy of the receiving
   system, typically in units of minutes.  While ESMTP provides a
   mechanism to determine if a message is too long in bytes, it is an
   unreliable guide for the composer when multiple encodings, multiple
   media, or variable bit-rate encodings are supported.

      (IANA-ASSIGNED-OID.2.9 NAME 'vPIMMaxMessageSize'
                        EQUALITY integerMatch
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
                        SINGLE-VALUE )

   The attribute indicates the maximum message length in seconds that
   the receiving mailbox may receive.
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2.10.  vPIMSubMailboxes

   This attribute indicates the presence of sub-mailboxes for the
   queried telephone number.  This information may be used to provide a
   post-dial sub-addressing menu to the sender.

      (IANA-ASSIGNED-OID.2.10 NAME 'vPIMSubMailboxes'
                        EQUALITY numericStringMatch
                        SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} )

   The allowable values include a list of sub-mailbox numbers with a
   numeric range of 1-9999.  The user interface may use this information
   to prompt the sender to select a sub-mailbox.  Spoken names
   associated with each sub-mailbox may be individually retrieved by
   subsequent queries to the recipient's VPIMDIR service.

3.  Security Considerations

   The following are known security issues.

   1) Service provider customer information is very sensitive,
      especially in this time of local phone competition.  Service
      providers require maximum flexibility to protect this data.
      Because of the dense nature of telephone number assignments, this
      data is subject to "go fish" queries via repeated LDAP queries to
      determine a complete list of current or active messaging
      subscribers.  To reduce the value of this retrieved data, service
      providers may limit disclosure of data that is useful for
      telemarketing, such as the textual name, and may disclose only
      information useful to the sender, such as the recipient's spoken
      name, a data element that is much harder to auto-process.

   2) In many countries, there are privacy laws or regulations that
      prohibit disclosure of certain kinds of descriptive information
      (e.g., text names).  Hence, server implementors are encouraged to
      support DIT structural rules and name forms [LDAPMODELS] as these
      provide a mechanism for administrators to select appropriate
      naming attributes for entries.  Administrators are encouraged to
      use these mechanisms, access controls, and other administrative
      controls, which may be available to restrict use of attributes
      containing sensitive information when naming entries.

   3) The LDAP directory service needs to be secured properly for this
      intended use.  [LDAPAUTH] describes a number of considerations
      that apply in this use.  In particular, this service provides
      unauthenticated, public access to directory data, and as such, it
      is vulnerable to attacks that redirect the query to a rogue server
      and offer malicious data.
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4.  IANA Considerations

   Reference RFC 3383 "Internet Assigned Numbers Authority (IANA)
   Considerations for the Lightweight Directory Access Protocol (LDAP)"
   [LDAPREG].

4.1.  Object Identifiers

   IANA has registered an LDAP Object Identifier for use in this
   technical specification, according to the following template:

   Subject: Request for LDAP OID Registration

   Person & email address to contact for further information:

      Greg Vaudreuil (gregv@ieee.org)

   Specification: RFC 4237

   Author/Change Controller: IESG

   Comments:

   The assigned OID will be used as a base for identifying a number of
   schema elements defined in this document.

4.2.  Object Identifier Descriptors

   IANA has registered the LDAP Descriptors used in this technical
   specification, as detailed in the following template:

   Subject: Request for LDAP Descriptor Registration Update

   Descriptor (vPIM): see comment

   Object Identifier: see comment

   Person & email address to contact for further information:

      GregV@ieee.org

   Usage: see comment

   Specification: RFC 4237

   Author/Change Controller: IESG

   Comments:
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   The following descriptors have been added:

   NAME                            Type    OID
   --------------                  ----    ------------
   vPIMUser                         O      IANA-ASSIGNED-OID.1.1
   vPIMRfc822Mailbox                A      IANA-ASSIGNED-OID.2.1
   vPIMTelephoneNumber              A      IANA-ASSIGNED-OID.2.2
   vPIMSpokenName                   A      IANA-ASSIGNED-OID.2.3
   vPIMSupportedUABehaviors         A      IANA-ASSIGNED-OID.2.4
   vPIMSupportedAudioMediaTypes     A      IANA-ASSIGNED-OID.2.5
   vPIMSupportedMessageContext      A      IANA-ASSIGNED-OID.2.6
   vPIMTextName                     A      IANA-ASSIGNED-OID.2.7
   vPIMExtendedAbsenceStatus        A      IANA-ASSIGNED-OID.2.8
   vPIMMaxMessageSize               A      IANA-ASSIGNED-OID.2.9
   vPIMSubMailboxes                 A      IANA-ASSIGNED-OID.2.10

   Where Type A is Attribute and Type O is ObjectClass
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